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1 Introduction 

This paper outlines two products which the OS Group is building. Briefly, these axe: 

1. Cheyenne: 

A high performance, highly available database machine built out of the QUARTZ database soft- 
ware and a MICA subset operating system running on ROCK systems. \Note that in this 
document the MICA subset is referred to as the database platform. \ 

2. Glacier: 

A high performance, tightly coupled compute server for DIGITAL'S hardware/software base. 

Both of products are described here with the assumption that the database platform forms the basis 
of the compute server. 

Both these products are assumed to be built around hardware which implements the PRISM archi- 
tecture and a base system derived from the current MICA design. This paper also briefly outlines 
some of the constraints on and design of MICA 

2 MICA Overview 



2.1 Requirements 

MICA has two basic requirements: 

1 . Immediate requirement: provide a common subset on top of which the Cheyenne and Glacier 
products may be built. 

2. Long term requirement: provide a state-of-the-art, portable operating system for future DIGITAL 
computer systems in the mid 1990s. This path is to be evolutionary. 



2.2 Goals 



1 . Meet the above two requirements. 

2. Robustness and reliability. In particular MICA must deal with all hardware and software errors 
in a reliable and predictable fashion. 

3. Quality: meet the expectations for a new operating system. 

4. Schedule. 

5. Performance: goals required for both short and long term requirements. 

6. Ease of installation and management. 

7. Eventual support for all PRISM implementations, both 32 and 64 bit systems. Immediate support 
for the MORAINE/ROCK processors and packaging. 

8. Provide a flexible I/O software architecture which support all ROCK hardware configurations 
defined as products. 

9. Provide a flexible system interface which allows MICA to be extended without modification or 
addition of component software executing in kernel mode. 



\Note that device support and object support are considered exceptions to thisA 

10. Provide a programming environment in which DIGITAL'S Application Integration Architecture 
may be implemented as the user applications' interface to MCA. ^rciutecture 

l T ^17° Ul i d then ^w tU ? y &?. a atandard apphcations interface to MICA which results in 

%^&E^&3£^ between mcA *** other DIGITAL operatin * 8 ^ tem8 



2.3 Non-goals 

1 ' kernel 6 ^^ documentation and Matures for user modification of the MICA executive and/or 
2. Constrained by any of DIGITAL'S existing operating systems. 

S^Sftffi2T\ iWCt 8y8tem 8endCe C0m P atibm ^ ™ th *»* of DIGITAL'S existing oper- 



2.4 Description 

!!^nM b ^ n t desi g ne J » "» °**^ oriented system with a rich set of services available from user 
mode (note that most of these services will eventually be accessed via the Application Integration 
Architecture hbraryX It is designed to support both the 32 and 64 bit PRISM arcWtSures TERES* 

STJT 11 ^ rt to mov ^ fr ° m a 32 " bit onl y ^Plementation to a 32/64-bit implementation when 
64-bit systems become available. Currently, key points in the design are: 

1 . Priority based pre-emptive schedule with provision for calss scheduling. 

2? km^ntetioS management System which 8u PP<>rt6 all allowed PRISM memory management 

3. Multiple threads of execution within a single address space (i.e. Tight weight processes"). 

4. A layered I/O architecture for the support of physical devices, file systems, and concepts such as 
volume shadowing, volume striping, virtual terminals, etc. P 

5. A centralized ACL based security architecture for all objects. 

6 ' ^^f subsystems: user processes which act as servers, with amplified security profiles and 

/or privileges, on behalf of chent processes, charging back resource usage to those clients. 
7. DECNET Phase 5 support. 

W ^] tgTOup ., Snpp ? 1 * : ""T distributed computing environment which provides file, record, se- 
curity profile and batch/print queue sharing. \Note that this is initially just support of DFSA 



2, 



8. 



9. Implemented almost entirely in the PILLAR language which provides block structure, strong typ- 
ing, structured condition handling and has been designed as a portable system implementation 

Sn?!& 2?^ i8 ^ Tms document is currently I 

being developed, given the above requirements. * f 



2.5 Dependencies 

\Dependencies are listed mainly for the short termA 

2.5.1 Internal Dependencies 

1. The PRISM SRM. 

2. The PRISM emulators and their configurations. 

3. The XMI Prism development system. 

4. Suitable 32-bit hardware and configurations. \The MORAINE/ROCK hardware. Note we even- 
tually need 64-bit configurationsA 

5. The 32-bit PILLAR compiler and an eventual 64-bit PILLAR compiler. 

6. Continued support and extensions for the 32-bit SIL language until the 32-bit PILLAR compiler 
is available. 

7. A PRISM C compiler and runtime library. 

8. A development strategy that allows transition from our current 32-bit PRISM emulator/SIL 
compiler environment to the 32-bit XMI-system/PILLAR compiler environment, and from there 
to the MORAINE/ROCK hardware. 

9. A testing strategy. 



2.5.2 Corporate Dependencies 

1 . The PRISM Calling Standard: immediately the 32-bit standard. 

2. DECNET Phase 5 architecture: both the architecture and the phased development of it for other 
DIGITAL products. 

In addition to these development issues, MICA must be validated for DECNET support. 

3. Corporate distributed security strategy, both for workgroup support and for its effect on MICA's 
security architecture. 

4. The FILES-11 ODS-2 specification. \Note that we have an ECO proposed and previously accepted 
for this but are will require VMS to support this ECO prior to our FRS for either of the two 
productsA 

5. The Applications Integration Architecture. \MICA will need a native implementation of this for 
software development both internally and externally. This implementation will be phased over 
various future versions of MICA as parts of AIA become definedA 

6. The corporate RPC. \Required for interface to protected subsystems A 



2.5.3 External Dependencies 

1 . RTL and debugger support from SDT. 



2.6 Outstanding Issues 

1. Testing: 

C ?£ e * t J?? A Project plans have not been specific regarding testing strategies. Given the goals 
of the initial products based on MICA, rigorous testing is a now even more important a require- 
ment of the development plan. 

2. PILLAR RTL: 

S^iSH"*? has very Uttle fa the way of b^t-in functions (such as I/O), an RTL is necessary 
lhis RTL is for internal use only (i.e. uuriug development) and may eventually be replaced by 
the superset functionality of a native Applications Integration Architecture. 



2.7 Resolved Issues 

1 . Relationship with ULTRK: 

We have resolved that there is no direct ULTRK compatibility designed into MICA. Tins does 
not preclude adding limited compatibility in the form of run time libraries at some later date. 

2. Failure modes and effects: 

We have planned a document, following after our design, which details the failure modes and 
eflects of our products. 



2.8 Impact on Previous MICA Design 

Given the current ordering of requirements for MICA is changing the previous design. Each of the 
two products denned below require only subsets of MICA A fully functional, general purpose MICA 
is not required until such time as the corporation needs MICA as a product in its own right. 

However, while Cheyenne and Glacier allow us to remove some functional component of MICA from 
the project, they both require extra functionality, specific to each product, be implemented by MICA. 

This is covered below separately for each product. 

Finally MICA wffl need to support both 32 and 64-bit PRISM architecture machines with a minimal 
of development effort once 64-bit systems become available. 

3 Database Platform Product: Cheyenne 



3.1 Requirements 

The only requirement of the database platform is that it provide the host environment required by 
the CXO QUARTZ project. In particular, this implies: 

1. Possibly new operating system interfaces and facilities. 

2. Specified performance goals, both I/O and operating system overhead. 

3. Specified availability goals. 

4. The end product must fit in with DIGITAL'S OLTP offerings. 



3.2 Goals 



1 . Quality, robustness and reliability. 

2. Support of the QUARTZ database software with a clean interface between MICA and the 
QUARTZ software. 

3. Operation of Cheyenne (i.e. platform and QUARTZ software) as a "black box", i.e. a "box" with 
a concisely defined and specified hardware and software interface for database transactions. 
Cheyenne must appear as a product, not a collection of products. 

\This does not imply that the platform would be built out of a single ROCK system. This "box" 
might in fact be composed of several ROCK systems connected by a high performance intercon- 
nect. This helps to insure availability goals and also an extensible system with a reasonable 
price/performance scaleA 

4. "Online" software installation or upgrade: replacement or modification of component parts while 
the entire system is running with minimal service interruption. 

\The current vision is that system software upgrades will take place while the system is running: 
to use the upgrade, a ROCK will need to be rebootedA 

5. Performance as required for the QUARTZ product: capable of supporting up to 600 tps in a fully 
configured system. 

6. A host environment that gives the reliability, availability, and fault tolerance required for the 
QUARTZ product. \Figures presented for QUARTZ are: 99.95 availahilityA 

7. Large amounts of disk storage: QUARTZ has the goal of simultaneous support of up to 2100 
HDAs giving 300 Gbytes total storage: one third large disks, two thirds small disks, all configured 
as 150 Gbytes of shadowed storage. 

8. Simplified system management, including remote system management. 

9. The Cheyenne is easily expandable from a basic hardware configuration to the top end configu- 
ration which meets or exceeds the above performance, availability and storage capacity goals. 

10. Eventual expansion to include a TP monitor. 



3.3 Nongoals 



1. Access or use without a client system. 

2. Access to processes on the platform oti 
system processes also include process* 

3. Use of the underlying system as a compute server. 



2. Access to processes on the platform other than database system processes. \Note that database 
system processes also include processes required for system management. \ 



3.4 Description 

The primary design center of the database platform is QUARTZ. The platform supplies all the oper- 
ating system services which the QUARTZ software requires. 

The platform is a MICA-subset which must minimally be capable of: 

1. Supporting free running server processes. 

2. Supporting the security model required by QUARTZ. 

3. Implementing the specific network transport and/or protocol required for communication with 
QUARTZ processes. 

4. Supporting a diagnostic environment for hardware diagnostics. 

In addition, QUARTZ requires that MICA support a common logging facility and high performance 
interprocess communications. Note that these facilities must function in a multi-ROCK Cheyenne 
configuration between the individual ROCK systems. 

Minimally, in addition to the QUARTZ requirements, MICA will need to provide remote system 
management, and high speed disk/file access. 

The current design model consists of a Cheyenne system composed of multiple ROCK systems inter- 
connected by high speed communication links. Through MICA QUARTZ would distribute its work 
load via these links and thus meet the performance, availability and connectivity goals. Communi- 
cation from client systems to the Cheyenne system would have no application visible knowledge of 
the internal organization or topology of ROCK systems making up the configuration. 

3.5 Major Dependencies 



3.5.1 Internal Dependencies 

1. MICA the subset needed for this product, and all its dependencies. 
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3.5.2 External Dependencies 



1. QUARTZ. 



2. Front-end software for access to QUARTZ servers. \The QUARTZ software will implement data 
management and a protocol for data access via LAN. lb sell this as a product, there clearly 
need to be front end packages which run on client systems and use the QUARTZ/MICA system. 
Currently no group in DIGITAL is developing such packages. It is our responsibility to make 
sure that plans are in place for this area so that DIGITAL has a complete productA 

3. The corporate RPC standard. \This is required by the system management model. \ 

4. DECnet Phase 5: the QUARTZ network interface. 

5. DECnet performance over the CI to/from VMS client systems. 



3.6 Outstanding Issues 

1 . System management: 

System management is carried out via a remote system management interface from a client 
system. The details of this and the role of the system console in this are in design. That 
QUARTZ will use the system management interface to activate utilities. The interface must be 
extendable in this respect. 

2. Security: 

What is the QUARTZ security model and how does it relate to the corporate distributed security 
model? 

3. Transaction processing platform: 

It has been claimed that the database server should be the basis of a future transaction processing 
(TP) platform. Since TP has particular requirements and constraints, we should investigate 
current TP models to ensure that our base system design does not prevent a platform from being 
built in the future. ,_ 

\There are examples in VMS today of original design decisions for the base system which later 
made it impossible or difficult to implement efficient TP systems on VAXesA 



3.7 Resolved Issues 

1 . Development environment for CXO: 

The development requirements for CXO have been identified and plans made to deliver the 
required environment in the right time frame. 

2. High speed interconnect for use between ROCK systems in a single Cheyenne configuration: 
The CI has been selected as the interconnect device. 

3. Files-11: 

QUARTZ will use Files-11 volumes for files. MICA shadow set support will also be used. 



4. Backup and restore facilities: 

The QUARTZ group will provide backup/restore/rebuild facilities for database files. 

5. Network support: 

DECnet will be the network software implemented for Cheyenne and used by QUARTZ. 

6. Transport protocols: 

The only transport protocols used by Cheyenne are DECnet protocols and SCA. 

7. Client systems: 

DECwest has no currently planned role in any client software or client systems. 

8. IPC: 

High performance interprocess communication is essential to the QUARTZ design. We are cur- 
rently designing this facility to meet their needs. 

9. Fault tolerance: 

We are dealing with the requirements of fault tolerance by providing the capability of multiple 
ROCK systems within a Cheyenne configuration. ROCK systems have the followine require- 
ments: 

1. 100% data integrity. 

2. Every system failure is detected and the source identified. VSystem" here includes hardware 
and softwareA 

3. Software must provide failover, reconfiguration and graceful degradation. 



3.8 Impact on Previous MICA Design 

The following facilities and areas of MICA are not believed to be needed for the Cheyenne MICA- 
subset operating system: 

1. All utilities (both VMS and ULTRIX), with the exception of: 

1 . The linker and PILLAR compiler. 

2. Some SET/SHOW/MONITOR functions. \Perhaps just an RPC server for these on the 
database platform with the actual command utilities integrated on the client systemsA 

3. BACKUP. \Not for database recovery - for entire volume backup and for installationA 

4. Some system management utilities. 

2. Terminal driver (except console support). 

3. DCL, shells or any command interpreter. 

4 " ft£ /SSS 00 " 1 n ° batch or piint man& S^ m ^^> very little (if any) local job management because 
QUARTZ processes are managed by QUARTZ and not by users directly. The only other processes 
m a Cheyenne system would be system management processes which are also very limited and 
controlled. 

It is very likely that the Process Architecture should be reviewed in light of the QUARTZ model. 
5. Local VMS or ULTRIX compatibility libraries as defined for MICA today. 
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6. Vector support. 

7. SDT languages and a large part of the RTLs. 

8. Workgroup/DFS support. 

9. RMS ISAM support. 

MICA is not a highly available system. It does meet certain goals of behavior in failure modes and 
it also guarantees data integrity. MICA must provide the basis to allow QUARTZ to be made highly 
available by using multiple MICA systems. The fundamental tool for this is a high speed inter-rock 
CI based IPC mechanism. 

4 Compute Server Product: Glacier 



4.1 Requirements 

We are expecting more specific requirements to be generated by our Product Management Group. 

However, one requirement currently identified and assumed in this document is that compute servers 
and clients must be members of the same Workgroup. 

4.2 Goals 

1 . Quality, robustness and reliability. 

2. Seamless integration with client systems: 

1 . Application compatible programming interfaces between client operating systems and Glacier's 
MICA operating system. 

2. Provide transparent image activation on the compute server from client systems. \This 
should make Glacier essentially an extension of a clientA 

3. Client systems are VAXes, in particular workstations. \There is some discussion of other future 
client systems, VAXmates for exampleA 

4. The client system interface to the compute server is designed for future support by multiple 
operating systems. 

5. The programming interface for Glacier is DIGITAL'S Application Integration Architecture. 

6. Performance: both processor, memory access/addressing and I/O speed/capacity. \Note that no 
specific goals have been identified in this areaA 

7. Glacier provides parallel and vector processing capabilities. 

8. Provide the b&sis from which a full functionality MICA operating system will be implemented 
as part of our new-architecture long range goal. 

9. Provide an easy to use, simple, and consistent user interface for system management. 

10. Layer support for the Glacier entirely on top of a client operating system with no internal 
changes. \This may be in conflict with goal 2 and tradeoffs may occur. \ 
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4.3 Nongoals 



1. Access to or use of the compute server without a client system. \Note that we do not include a 
LAT Server as a potential client system.X 

2. Full participation in local or wide area networks as a node distinct from any client nodes. 

3. Implement MICA system services that are completely compatible with VMS or ULTRDX svstem 
services. ' 

4. A DECwindow server distinct from any client system. YThis is a non goal because DECwindow 
services are provided by client systems, not the compute server itselfA 

5. Making MICA system services directly available to applications. | 



4.4 Description 

^current model of Glacier is a system which derives most of its programming environment and 
some of the programming interface and from its client systems. Glacier itself has system service 
capabilities and also uses services in its clients to complete requests from application images running 
on the compute server. This model is described in: running 

docd$ : [MICA.papers . rpc-compute -server] rpc-compute- server .paper 

The associated files in that directory discuss specific aspects of the model. What follows is a brief 
description of this model. 

T G i a T?%K iS ba9Cd ° D a PM SM/MICA system that is connected to its client systems by a high-speed 
LAN The server is accessed by client .systems and largely acts as a slave to Ihose systems, lLommg 
an extension of each client system A process, created by a client system, in the compute server, is 
always associated with the job in the client system that created it. Such processes are called bound 

pFOCGSSBS ■ 

Each bound process can make use of two types of system procedures: those which use native MICA 
system system services and those which make RPC calls back to the client system. In this wav a 
^S^ 688 1S &™ 00 **™ 1 °™ XX* ■»» PRISM specific facilities (such as memory management, 
multiprocessing, scheduling, etc ) while having capabilities and context of its assodateTjWcUent 
system available (such as logical name context, command information, user information, etc.). 

In order to meet the goal of application transportabihty between client and server, bound processes 
may only use services provided by DIGITAL'S Application Integration Architecture. AIAis designed to 
provide a system-independent implementation of system services/facilities. These include most of the 
SL^^ ■* 'ET^rf ^ 8ten ? normaU y directly provides, plus facilities like DECwindows. This 
nnplementation of the AIA is built on top of the two possible types of system procedures described 

Key to the Glacier design is that activating an image on a compute server should be indistinguishable 
from activating an image on a client. Therefore, a bound process has the following properties: 

1 . Its maximum life span is that of the process which created it. 

2. It has the same ^effective security profile as the job/process which created it. \The FRS product 
will use DECnet proxies for thisA ^ 
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3. It is associated with a specific process running on the client system in the associated job. That 
process forms the bound process' RPC server for nonlocal system procedures. 

Thus, from a client's point of view, Glacier is a tightly coupled extension of its computing resources. In 
the current model, no client is aware of any other client's use of the compute server: bound processes 
on the compute server are unaware of each other. 

From Glacier's pomt of view, in addition to bound processes (which are essentially slaved to client 
jobs) there are also free-running processes. These are necessary to implement server processes for 
facilities such as system management and workgroups. Free-running processes have the following 
important characteristics: 

1. All the native MICA system procedures are available to them but they have no remote client 
procedures available since they are not associated with any particular client. 

2. While they may be started via a special mechanism from a client, they have a life which is not 
implicitly linked to any job on any client. \Note that this makes the management and failure 
detection of these processes nontrivialA 

3. They are not automatically tied to the security profile of any client job. 

4. Specific privileges are required for a client to create them. 

The only interface to Glacier is via a client system. Client systems access the compute server via the 
RPCs' transport and via workgroup support (i.e. DFS for FRS). The RPC transport is bi-directional: 
client systems use it to create processes and compute server processes use it to make calls to client 
Bystems. Glacier has no directly connected terminals (other than the system console), so that all 
terminal usage by compute server processes is via the DECwindows component of the AIA or via 
callback RMS. 

File access for a compute server is either provided by the local file system to locally attached disks, 
or via DFS support to disks located on client systems. It is implicit in this model that the compute 
server is in the same workgroup as its clients. DFS will provide file access services for FRS and is 
eventually expected to provide both record services, and the complete workgroup distributed security 
environment. 

A compute server may also make its local disks available to processes running on client systems via 
the workgroup. 

DFS and RPC transports are the only networking requirements which explicitly need to be imple- 
mented on the compute server. Other LAN/WAN access by applications on the compute server is 
obtained via callbacks to client systems or via using the DECnet facilities provided by MICA. 

4.5 Major Dependencies 



4.5.1 Internal Dependencies 

1 . MICA: the subset needed for this product. 

2. DFS architecture implementation. 
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4.5.2 Corporate Dependencies 

1. A satisfactory RPC standard and the tools to use and implement that standard. 

\Satisfactory means: capable of being used in our model. This may mean greater involvement 
in the review/specification of the corporate RPC standardA involvement 

2. DIGITAL'S Application Integration Architecture. 

^S^T^Z *5 e yes**™*™?™ quantity. Its central role in our model implies our future 
ptrSy^Ss^teu^ 8 ^^ " ^^-'"^P-tiallyanativelSlCAissueS 

iW^^ETJ^ ^ °PP° rtunit y to hel P specify this architecture. However, the architec- 

3. Corporate distributed security strategy: critical for post FRS workgroup support, 
aetata SRcT^ ^ *"" "^ ^ ^^^ ° f Butler ****** ™ th the ™*» 

*' «3f^ ^J™* f *? *** ^ item *"* *" ""^ consequences since it is unclear what 
Sde^ [fS> Strategy 1S ' H ° WeVer ' * iS n ° W dear *"* VLTBSK 8 y stems ^ »« S2 "5 

5 - 2^^ 1 2irri a B aa!5a wm need to *■* «■* implement * together ** ■* 



4.5.3 External Dependencies 

1 . Support of DFS by other client operating systems. 

2. Distributed debugger support from SDT 

3. SDT compilers. \Not for development of the product, but for availability at FRSA 

4. The DFS product for post FRS workgroup distributed record and file access services. 



4.6 Outstanding Issues 

The following are the open issues surrounding our current model: 

1. Division of system services between local and remote: 

2. Changes in client operating systems: 

^ZH^JS^^ "^ ^ a ?. been made of ^w to implement the requirements of this compute 
S£TL? i? "^ P * 6 ^ 81 ^? nt °P« a, W ^tems- K is possible Sat compute server support 
canbe layered on top of any dient system, as desired. If not, any change i required mcKt 

ffiSaSE* * identified -* a ^ ^ UP ° n ** other^eC^grSi^ 
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\DECwest owns the "total system" problem for this productA 

3. Quotas and accounting: 

Should quotas for a bound process originate from the client system or should they be defined 
on Glacier? Is accounting information only returned to the client system when a bound process 
exits? Is it captured on Glacier? 

4. Application availability: 

Currently no applications running on DIGITAL supplied systems use the Application Integration 
Architecture. Given that this architecture is currently being design and is expected to take some 
time to be available to customers, it is unlikely that there will be many applications available 
at FRS of Glacier which use this architecture. 

Thus, to provide some initial attraction for the product, it may be necessary to provide support 
for some VMS or ULTRIX system services via the RPC techniques described above. To resolve 
this issue, applications typical of those which would be run on Glacier should be studied for their 
requirements in terms of host services. 

5. Failure modes and behavior: 

Little in-depth study has been made of dealing with server and network failures. These should 
be completely characterized for the product and documented. The question of failover (thought 
to be too large a problem for FRS) should be at least characterized and future product goals 
identified. 

6. RTL versus AIA 

It is unclear exactly what AIA will include. Currently, AIA is known to include the SMG$ and 
parts of the LIB$ VMS libraries. It may also include the general PILLAR RTL. 

We must resolve what general RTL support is required. If AIA includes what currently is defined 
as our RTL, then implementation and definition will continue as a part of the MICA AIA project. 
If not, we must plan and produce the RTL. 



4.7 Resolved Issues 

1 . The availability of general RPC support for user written applications: 

The FRS product will not make general RPC support available to user written applications. RPC 
support will be design with that goal in mind for some future release. 

2. Transport protocols: 

The only protocols implemented for Glacier are DNA protocols and the DFS protocols. 

3. Network support: 

DECnet will be implemented on Glacier. 

4. Model for system management: 

The system management model has been selected and is in design. 

5. Scaling: 

The issue of scaling has been largely posponed to a future release. For now, when a client may 
use multiple compute servers, the target server will be selected by a fairly simple mechanism 
(such as a logical name). 
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6. Character cell terminal support: 

Glacier will provide support for character cell terminals. This support will be minim al line I/O 
unless requirements show a need for more functionality. The maJnnum amounTSwSnahtv 
which would be implemented is the SMG library. iuncuonanty 

7. Client operating systems: 

S^iShSa" 1 VMS "" CKent 0perating systems for *"■ P"d«*. \Note that there may be 

4.8 Impact on Previous MICA Design 

The impact on MICA includes all points mentioned for the database platform However Glari^r 
requ^s the following MICA facilities be implemented on the dSLfSSKn «E? ^2SJ 

1 " 1^A ]iC&ii0n Integration Architecture library. \Note that the DECwindow part would be RPC 

2. Workgroup support (note that this implies support of DFS). 

3. Vector support. 

4. SDT languages, RTLs, etc 

5. The C compiler and C-RTL. 
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